Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/create/package.json`:
- Around line 27-33: The test:coverage script is missing the manifest generation
prerequisite that other scripts include. Add "npm run generate-manifest &&" to
the beginning of the test:coverage script command to ensure the generated
manifest file exists before running coverage tests, following the same pattern
used in the build, dev, test, and test:watch scripts.

In `@packages/create/scripts/generate-manifest.mjs`:
- Around line 76-83: The readdirSync call in the visit function iterates over
directory entries in filesystem order, which is non-deterministic across
different environments and causes inconsistent manifest generation. Sort the
array returned by readdirSync before iterating over it with the for loop. Apply
the same sorting fix to the other location mentioned (around lines 113-116)
where readdirSync is also used without sorting to ensure deterministic manifest
ordering regardless of filesystem.

In `@packages/create/src/edge-add-ons.ts`:
- Around line 36-38: The code fetches remote add-ons via
loadRemoteAddOn(addOnID) without validating the URL, creating an SSRF
vulnerability if addOnID originates from external input. Additionally,
loadRemoteAddOn likely processes HTTP responses as JSON without checking status
codes. Add URL validation before calling loadRemoteAddOn to reject localhost
addresses, private IP ranges, and cloud metadata endpoints. Modify
loadRemoteAddOn to check the HTTP response status code and only parse JSON for
2xx responses, rejecting error responses. Apply these same hardening fixes to
the similar remote add-on loading code at lines 76-79.

In `@packages/create/src/edge-config-file.ts`:
- Around line 17-24: The return object in this function uses the `...rest`
spread operator which inadvertently includes sensitive fields like
`envVarValues` and `addOns` in the persisted config file, creating a security
risk. Instead of spreading rest, explicitly list only the safe fields that
should be persisted in the edge config file. Destructure out `envVarValues` and
`addOns` from the options parameter along with the other fields already being
destructured, then return only the intended config fields (version, framework as
an id, chosenAddOns as ids mapped from the objects, and starter as an id if
present) without using the spread operator for remaining fields.

In `@packages/create/src/edge-create-app.ts`:
- Around line 565-567: The cd instruction string being printed uses the
incorrect variable `projectName` instead of `targetDir`. In the conditional
expression around line 565-567 in edge-create-app.ts, replace the `projectName`
reference with `targetDir` in the template string to ensure users are directed
to the correct output directory, which may differ from the project name when the
output directory is specified separately.
- Around line 445-446: The regex pattern in the RegExp constructor directly
interpolates the key variable without escaping, which means regex metacharacters
in the key will be treated as operators rather than literals. Before
constructing the pattern, escape the key using a regex escape utility function
(such as escaping characters like . * + ? [ ] ( ) etc.) so that special
characters are treated as literal characters in the pattern match. This prevents
keys with regex metacharacters from unintentionally changing the regex behavior.
- Around line 396-397: The calls to installShadcnComponents and setupIntent
functions are executing without checking whether the install flag is disabled in
options. Add a conditional check before both function calls to verify that
install is not set to false (i.e., check if options.install is not explicitly
false) to prevent running these networked commands when skip-install mode is
enabled.

In `@packages/create/src/edge-environment.ts`:
- Around line 37-42: The startRun method clears the output object but does not
reset the persistent in-memory files map, causing state leakage when the same
environment instance is reused for multiple runs. In the startRun method, in
addition to clearing the output properties, also reset the files map to an empty
object to ensure each run starts with a clean state and prevent carryover of
files from previous runs.
- Around line 98-103: The `exists` and `isDirectory` methods fail to handle root
path cases (represented as `.`) because `hasDirectory` expects a `./` prefix
that normalized file keys never contain. Add explicit checks in both the
`exists` and `isDirectory` functions to detect when the input path represents
the root directory (normalize to `.` or empty string after normalization) and
return `true` immediately for these cases, since the root always exists and is a
directory. Only call `hasDirectory` for non-root paths.

In `@packages/create/src/edge-file-helpers.ts`:
- Around line 38-43: In the relativePath function, normalize the to parameter
the same way as from by applying the backslash-to-forward-slash replacement
before processing it. Currently, from is normalized with replace(/\\/g, '/') but
to is used directly without this normalization. Add a line to normalize to by
replacing backslashes with forward slashes, similar to how from is normalized,
to ensure consistent path handling regardless of whether paths use backslashes
or forward slashes as separators.
- Around line 18-25: The toCleanPath function uses startsWith for path matching
without ensuring path segment boundaries, which causes incorrect slicing when
there's a partial match (e.g., normalizing /apple/file with base /app
incorrectly yields le/file). Fix this by adding a boundary check after the
startsWith match in both the normalizedPath.startsWith(normalizedBase) condition
and the pathNoDrive.startsWith(baseNoDrive) condition. Ensure the character
immediately following the matched base is either a path separator or the end of
the string before performing the slice operation.

In `@packages/create/src/edge-package-json.ts`:
- Around line 114-118: The additions array in the createPackageJSON function is
hardcoding the inclusion of TypeScript and Tailwind optional packages regardless
of user selection. Modify the additions array to conditionally include
options.framework.optionalPackages.typescript and
options.framework.optionalPackages.tailwindcss only when those options have been
explicitly selected by the user (check options.typescript and
options.tailwindcss flags). Similarly, update any template rendering logic
(referenced in lines 131-137) to use the actual selected options instead of
hardcoded TypeScript/TSX values, ensuring the correct file extensions and
configurations are used based on what the user chose.
- Around line 153-160: The catch block in the try-catch statement around
JSON.parse(render(addOn.packageTemplate, templateValues)) only logs the error
and continues execution, which allows incomplete packageJSON data to persist and
cause failures later. After logging the error with console.error, throw the
caught error to fail fast at the source of the problem rather than silently
continuing with invalid addOnPackageJSON data.

In `@packages/create/src/edge-template-file.ts`:
- Line 183: The file.replace method in the line with convertDotFilesAndPaths
will remove all instances of `.ejs` from the filename, not just the file
extension at the end. Fix this by modifying the replace call to use a regular
expression pattern that matches `.ejs` only at the end of the string using the
`$` anchor, so that filenames containing `.ejs` in the middle are left
unchanged. This ensures only the actual `.ejs` template extension is removed.
- Around line 127-133: The templateValues object in the edge-template-file.ts
file has hardcoded TypeScript values (typescript: true, js: 'ts', jsx: 'tsx')
that ignore the user's language preference. Replace these hardcoded values with
conditional values based on options.typescript: set typescript to
options.typescript, js to either 'ts' or 'js' depending on whether
options.typescript is true, and jsx to either 'tsx' or 'jsx' depending on
whether options.typescript is true. This ensures the correct file extensions and
flags are used for both TypeScript and JavaScript projects.

---

Nitpick comments:
In `@docs/cli-reference.md`:
- Around line 47-85: Add documentation for the includeExamples option in the
Worker-safe programmatic generation example. Include the includeExamples
property in the options object passed to the createApp function call to
demonstrate how users can control example code generation. Add a brief comment
or explanation in the documentation explaining that this option controls whether
example files are generated during app creation, helping users understand they
can set it to true or false based on their needs.